Subject: can our loopprevention do it?

From: Choon Lee <[email-masked]>
Date: Wed, 8 Sep 1993 17:17:34 -0700

Dave,

Hello. Thanks for sharing with us the discussions that you had within IBM.
I'm glad that there is work done "behind the scene" :-)

In one of my earlier mails, I've outlined an approach to be considered for dealing
with the various problems that come along with loops. I'll try to apply this
approach on the various problems that you have outlined, and see if this approach
is satisfactory in dealing with the problems. This ought to determine if this
approach is worth further investigation.

First, let me describe the approach (the modified TEST packet method) in more detail. 
Borrowing the diagram that you have provided (diagram below):

When station [X] broadcasts a test frame seeking station [Y], the test frame is picked
up by both DLSw J and K, and each forwards CANUREACH to its respective DLSw partner.
DLSw L and M each put a test frame on LAN segment B on behalf of [X]. However, 
additional information is appended to the TEST frame (actually, since the CANUREACH
does not carry data info, the "additional info" is the only data info in the TEST 
frame). The info that gets added consists of (a) a virtual "ring" number, and 
(b) min (my IP addr, partner IP addr). Hence, the TEST frame that L sends out has VR and
IP addr of J (assuming J's IP addr < L's IP addr); and the TEST frame that M sends 
out has VR and IP addr of M (assuming M's IP addr < K's IP addr). The VR carried in
both frames must be the same (similar to the source routing case).

When the TEST frame that L sent is picked up by M, since it has the same VR, the 
frame is passed up to LLC wherein a corresponding link station is found (actually
a "mirror" link station - since DA and SA are reversed). The IP addr in the TEST
frame (J's IP addr) is compared with M (the smaller of K and M), and assuming that
M is greater than J, the link station is marked as "unreachable" (which later
*prohibits* the TEST response from [Y] from resulting in ICANREACH to K). Also, M
clears its bridge table for station [X] (so that response from [Y] can get to it).

For L, it receives the TEST frame sent by M. It goes through the same logic as M,
but since it has a smaller IP address (J < M), this TEST frame is dropped. Also,
L clears its bridge table for station [X] so that it can later receive TEST response
from [Y].

Next, [Y] sends its response which is picked up by both L and M. L then sends ICANREACH
to J like it would normally do. M throws the received TEST response packet away (maybe
it should send DONTBOTHER to K? The DONTBOTHER can actually be sent earlier, when it
enters the "unreachable" state).

The end result is that only one DLSw link (J-L) gets set up between [X] And [Y].

In the case of, say, M receiving the modified TEST frame from L before a CANUREACH 
from K, it will send a CANUREACH to K. It would then have to do similar thing when 
it gets a CANUREACH from K later.

What about Netbios?

Now assume that [X] and [Y] communicates with Netbios. [X] sends out a NB_Name_Query
addressed to a group address. L and M gets NETBIOS NQ from J and K respectively.
Before they each send out a NB_Name_Query on LAN segment B, they each send out a
TEST frame that has the VR and IP addr info. The purpose of this is to "knock"
the other DLSw path out. Since I do not know a great deal about the NetBIOS protocol,
I'm not entirely sure that this can take care of all the problems.

I'll make the following comments to your append based on the above method just
described.

>> 
>> This append is the result of some discussions held among Roy Dixon, Allen
>> Carriker, Gene Cox and me (Dave Butler) here at IBM.  We think there are
>> three problems that should be addressed in this siglet.
>> 
>> 1.  looping of SNA test frames and NetBIOS NQ (Name Query),
>> 2.  duplication of UI frames addressed to a group (functional) address
>>     (i.e. NetBIOS), and
>> 3.  excessive frame copying by transparent bridge.
>> 
>> Let us take these one at a time...
>> 
>> LOOPING OF SNA TEST FRAMES AND NetBIOS NQ (Name Query)
>> 
>>       LAN segment A                          LAN segment B
>>             |-                                     |-
>>            -|  +--------+              +--------+  |
>>             |--| DLSw J |--(TCP cnxn)--| DLSw L |--|
>>             |  +--------+              +--------+  |-
>>        [X]--|                                     -|
>>             |-                                     |--[Y]
>>            -|                                     -|
>>             |- +--------+              +--------+  |-
>>             |--| DLSw K |--(TCP cnxn)--| DLSw M |--|
>>            -|  +--------+              +--------+  |-
>>             |                                      |
>> 
>> Suppose that station [X] broadcasts a test frame seeking station [Y].  The
>> test frame is picked up by both DLSw J and K, and each forwards CANUREACH to
>> its respective partner DLSw.  DLSw L and M each put a test frame frame on LAN
>> segment B on behalf of [X], L's test frame is copied by M, and M's is copied by
>> L. Both DLSw L and M forward CANUREACH to their respective partners, J and K.
>> DLSw J and K each generate an test frame on LAN segment A, and the loop is
>> complete.
>> 
>> Note that after one turn around the above loop, the test frames transmitted
>> by J and K are indistinguishable from one that might be transmitted by [X]
>> itself as it retries its connection setup.  DLSw will simply drop these frames
>> in the same way that it would drop a connection-retry test frame from [X].
>> Recall that retries are not carried on the WAN, but instead are retried on the
>> "other" side of the WAN.  This is one of the ways DLSw reduces the WAN traffic.
>> So the loop is not infinite, it is terminated after a single turn, by a
>> mechanism that is already part of the DLSw definition.
>> 
good point.

>> Note also that the above scenario can lead to failure of the session to
>> start, depending on timing. If the transparent bridges in DLSw L and DLSw M
>> both learn that station [X] is on LAN segment B, they will not copy the test
>> response from station [Y].
bridge table (cache) clearing is done when a "modified" TEST packet is identified
by LLC.

>> 
>> As our discussions have progressed, we have become more and more convinced
>> that the spanning tree algorithm is not a solution to this problem, for the
>> same reasons that others have already expressed:  because the DLSw connection
>> forwards SNA and NetBIOS only, and participation of DLSw in the spanning tree
>> may cause some other parallel bridge connection to enter the blocked state.
>> With the other connection blocked, SNA and NetBIOS could be transported, but
>> the other protocols would be broken.
>> 
>> We recommend caution in considering solutions that require data to be
>> carried in the test-frame.  The i-field of test has been used for other
>> purposes (IBM 3174, for example), so cooperation among the (various?)  users
>> would be required.
>> 
Yes. This could be the killing blow for the described approach. Is additional 
I field absolutely prohibited? Or can it be added in such a way as to not affect
the 3174?

>> DUPLICATION OF UI FRAMES ADDRESSED TO A GROUP (FUNCTIONAL) ADDRESS
>> 
>> I don't think this topic has been mentioned before in this forum.  The
>> looping can originate in the same way as for test frames and NetBIOS NQ, but
>> there is no simple mechanism to detect and stop it.  Since these frames are
>> multicast to a group address, they must be forwarded by each data link switch,
>> and if the network configuration has any loops, these frames will never stop
>> circulating.
>> 
Hopefully the special TEST frame can remove the loop.

>> On token-ring LANs, there is no loop, because the routing information in the
>> packet allows forwarders to avoid broadcasting the packet on rings (including
>> the DLSw virtual ring) where it has already been broadcast.
>> 
>> For either token-ring or Ethernet LANs, whenever there are parallel data
>> link switches between a pair of LAN segments, each DLSw will copy these frames
>> to the WAN, resulting in unnecessary duplication of traffic.
>> 
Isn't it true that even if there is no *parallel* data link switches, each DLSw on
the LAN segment copies as many times as there are DLSw partners?

>> IBM's experience is that NetBIOS installations have a significant amount of
>> traffic of this type.
>> 
>> Any solutions that come out of the SIGlet should address this problem as well
>> as the looping of test-frames and NetBIOS NQs.
>> 
>> EXCESSIVE FRAME COPYING BY TRANSPARENT BRIDGE
>> 
>> In the 6611 implementation, the transparent-bridge function in the router is
>> used to attach the DLSw to transparent-bridged LANs.
>> 
>> The bridge learns the locations of stations on each side of the bridge by
>> watching the frames that pass by (learning), and selectively copying only those
>> frames for which the destination is on the other side.
>> 
>> When a DLSw transmits a test frame to the transparent-bridged LAN on behalf
>> of another station, the bridge attaching the DLSw to the LAN learns that the
>> origin station is reachable through the DLSw.  This learning occurs in the
>> bridge regardless of whether this DLSw is ultimately selected to carry the
>> prospective session.  Forever after, the bridge will copy frames destined for
>> the station from which the test frame came.  They are passed across the channel
>> to the LLC, which drops the frame since there is no link-station.  This
>> unnecessary copying of frames contributes to the load on the channel and the
>> processor.
>> 
If the transparent bridge has the capability of placing a certain MAC address on
the hardware such that all frames with DA that matches that address does not get
copied, then this problem is solved. I know of certain bridge vendor that has
that capability. But this is an optimization that could be too expensive.

>> To illustrate, suppose that in the configuration shown above, the
>> transparent bridge in router L learns that [X] is on LAN segment A, but the
>> DLSw connection between [X] and [Y] is established using routers K and M.
>> Traffic bound from station [Y] to [X] will be copied by the transparent bridge
>> in router L and must be discarded by the DLSw, even though router L is not
>> involved in the DLSw connection.
>> 

Please comment.

Regards,
Choon Lee
3Com Corp